Went through this against ts-sdk 0.13.8 piece by piece. Solid change, docs and tests are thorough. One thing I'd sort before merge, then a few smaller notes.

The parity story holds up: TS's injectClientPubkey is opt-in (default off, nostr-server-transport.ts:229) and writes to the on-wire _meta (utils.ts:47), so doing it always-on through local rmcp extensions instead is a reasonable call.

The plaintext path doesn't verify the event signature, but ts-sdk does. This is half of ts-sdk's identity-forgery fix (ContextVM/sdk#64, PR ContextVM/sdk#69). That fix verified both inbound paths: the decrypted inner event, and the unencrypted one (a separate commit, fix: verify unencrypted event signatures). We port the first at server/mod.rs:1698 (inner.verify()), but the plaintext else arm (server/mod.rs:1741-1759) trusts event.pubkey without ever calling verify(). ts-sdk verifies it in handleUnencryptedEvent (event-pipeline.ts:162), and the reasoning is on the encrypted path just above (event-pipeline.ts:113-116): an attacker can put any pubkey in the plaintext and bypass allowlists. We gate the auth allowlist on exactly that pubkey (server/mod.rs:1789), so it lands here too.

To be clear it isn't exploitable on the default transport: nostr-sdk's RelayPool already verifies inbound signatures (nostr-relay-pool-0.44.1, relay/inner.rs:1233), which is the whole reason ts-sdk has to do it in-app, since nostr-tools doesn't. It only bites with a custom RelayPoolTrait that skips verification, like our own MockRelayPool. RelayPoolTrait is public, so as written, caller identity quietly depends on which pool someone plugs in. The gap predates this PR, but this is the change that makes it matter, since it promotes event.pubkey into first-class handler identity. I'd just mirror the gift-wrap arm:

// verify() also checks event.id matches its content, which we rely on for
// correlation and the request id below. Redundant against the default pool,
// but it keeps identity independent of the pool impl.
if let Err(e) = event.verify() {
    tracing::warn!(target: LOG_TARGET, "Plaintext event signature verification failed: {e}");
    continue;
}

Not a hard blocker given the default pool, but it's cheap insurance, and I'd rather caller identity not hinge on an undocumented assumption about the transport.

A few smaller things:

Scope / description. Three separate changes are riding together: ClientPubkey (the parity piece), InboundEvent, and the CEP-41 open-stream fix. The description only really covers the first, so it might be worth mentioning all three, since the CEP-41 fix isn't described at all and a reviewer could miss it.

InboundEvent. No issue with it going beyond the reference. TS only surfaces the event lazily via getNostrRequestEvent (nostr-server-transport.ts:627), and injecting it directly is nicer. One real gap though: it's silently None for oversized (CEP-22) requests. The reassembly path sends a real sender_pubkey with event: None (server/mod.rs:2211-2214), so a handler can't tell "no event" from "the request was too big to fit in one." That's exactly the MLS key-package case the description pitches, since a key package is the kind of payload that goes oversized. At least worth making the docs honest about it.

ClientPubkey on synthetic requests. It's injected unconditionally, so the internal announcement/init requests get a ClientPubkey that's really the ANNOUNCEMENT_REQUEST_ID sentinel (InboundEvent is correctly None there). ts-sdk only ever injects a real event.pubkey. Might be worth skipping it for those, but gate on the sentinel value, not on event.is_none(), since the oversized path above carries a real pubkey with no event.

Couple of things I checked that are right as-is: evicting the whole session on a writer probe timeout matches ts-sdk's handleProbeTimeout (open-stream-factory.ts:307), and ClientPubkey(String) as raw hex is correct, since a typed key would drift from _meta.clientPubkey: string.

Really nice work overall. The encrypted-path verification, per-request extension isolation, the whoami/whoami_event coverage across all three encryption modes, the keepalive tests plus the silent-client regression, and documenting the FFI omission instead of leaving it implicit all stood out.

LGTM, all items addressed! Just worth updating the PR description to cover InboundEvent and the CEP-41 fix, since right now it only mentions the pubkey injection.